是的，2020年五月，也就是一年前的 #TDD與持續重構 梯次，今天還有同學會在上面問問題，而我也樂於分享一下我的看法一起交流。
從他的發問例子，pull member up 加上 namespace 的 Money, 讓我想到他正在用 Ct 練習 Kent Beck 的 TDD by Examples part 1 的 Money Example.
所以順便分享了一下我覺得不要錯過的重點（美的地方）。
至於那個 builder 的視角，並不是書裡面寫的，而是我會想從 Expression 往下延伸嘗試的設計視角，這樣可以簡單的把一堆 計算 的內容跟組合封裝起來。
試過一次，覺得蠻有趣的，但畢竟不是真實產品等級，我的領域知識也還不足，不知道那樣的 builder 概念在該領域會不會碰到什麼不合適的使用場景就是了。
多嘗試，多從自己的輸出取得回饋，才能真的學到書本內想帶出來的知識點。
—
何況我還有 Kent Beck 可以請教 ❤️
補上在學員群組分享的片段：
—
好的抽象概念（隱喻）真的是可遇不可求，需要大量練習，如果大家有仔細看書的話，Kent Beck 也是在正式做這個例子十多遍以上，才領略到這個設計的角度。
這也是為什麼 一個足夠複雜 概念夠多的題目或需求，值得我們反覆練習
https://tdd.best/courses/classic-tdd-by-example-video-training/
我在這個影音課希望可以達到的效果也是如此，因為我自己一個語言做了十多遍（我目前有準備三個語言的版本 Java, C#, Python)，很多遍的設計角度都不一樣。
有一些在前面幾次直覺不可行的，在後面幾次的岔路時，我就決定走走看。
大部分直覺都是對的，但也有幾次走出很不一樣的路。
如果「只練一次」，是沒機會走出那麼多不同的設計角度的。
同樣的，如果寫程式太慢，或是取得回饋的週期過長，你能嘗試的設計方案就會跟著變少，能學到的東西變少，同時要追求「剛好且簡單」的解決方案，機率就會變低。
大家可以想想，如果是自己在做 Money Example, 在真實世界有時間壓力底下，可能這輩子都不可能想出這樣簡單的設計方案。
如果都只在真實工作才學習、練習，那技能就會一直停滯。
永遠都只能用那種直白、procedure式、脆弱的流程設計角度，因為只會這種方式，自然自己最快的完成方式 就只會有這種副作用、複雜度最大的設計方式。
所以要多練 讓自己有多種視角，TDD 也是一種先從使用端來設計的視角，所以易用性的設計角度，物件的互動角度才能在這種視角被凸顯出來。
Search